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Generic service request procedure in a multimode system 
Background of the Invention 

1. Technical Field 

5 The present invention relates to telecommunications and, more particularly, to 

mobile telecommunications terminals and utilization of network services. 

2. Discussion of Related Art 

Multimode terminals are getting more and more popular. Multimode terminals are 
10 capable of operating on different system modes (using different radio access 

technologies and/or able to attach to different core networks). Examples of different 
system modes are GERAN, WCDMA, TDMA, AMPS, CDMA 2000, WLAN, 
Bluetooth etc. Multimode networks may support different types of interworking 
between the system modes supported by the terminal. 

15 

Currently the terminal already provides some information about its capability in 
different system modes, making the network aware which services the terminal can 
support in different system modes. An example is a GERAN terminal indicating its 
capabilities; in addition to the capabilities for GERAN access technology, also if it 

20 supports WCDMA and/or CDMA 2000 radio access technologies. The terminal may 
have quite different support for services depending on the serving system mode. For 
example, simultaneous packet and circuit switched service is only possible if both the 
GERAN network and terminal support dual transfer mode (DTM) while this service is 
always supported by a GERAN/UTRAN dual mode terminal when served by 

25 UTRAN. Similarly, if the GERAN network does not support high speed data, then the 
circuit switched data rate is limited to 9.6 kbit/s for GERAN access while a higher 
data rate is likely available through WCDMA and an even higher data rate through 
WLAN. GERAN again might support a location service when any of the other modes 
supported by the multimode terminal do not support this service. However, when the 

30 terminal requests a service, the request is limited to the services supported by the 

terminal in the currently serving system mode, additional restrictions may be set if the 
network indicates non-support for some specific network capabilities. 
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In 3GPP standardisation, different vendors are proposing different ways to solve 
specific problems where GERAN capabilities are not enough to support a service and 
thus inter-system change from GERAN to UTRAN is proposed. For example, 3GPP 
TSG-SA WG1 #21 (Sophia Antipolis, France June 7-11, 2003) proposes to allow a 

5 UE that has CS multimedia capability and that is camping on a GERAN cell but is 
also within UTRAN coverage to setup a CS multimedia service using a UDI 64 kbit/s 
bearer in UTRAN. Another example is 3GPP TSG-SA2 #33 (also June 7-1 1, 2003) 
which introduces a proposal for a new procedure for dual CN connection where a 
UMTS/GSM terminal roaming in GSM in the neighbourhood of UTRAN coverage is 

10 allowed to request a dual CN connection to the BSS, even if the MS is not Class A or 
if DTM is not supported by the MS and/or the BSS, in order to indicate that a 
handover or a cell change order to UTRAN should be favoured by the BSS. 

Currently there already exist other similar problem cases for other services as well, 
15 and the above mentioned proposed solutions by different vendors are not applicable 
for solving the problems for these other cases but are only directed to narrow and 
particular problems. The difficulty in these solutions is that they are targeted to a 
specific problem and are not suitable for solving the issue in generic way (though, 
these proposals are not actually acceptable to solve the mentioned problems). In this 
20 invention disclosure it is shown that a generic mechanism should be applied into the 
3GPP specifications to solve the problem in a generic way. 

A further example solution is given in the EPO patent No 0716797B1 where the 
mobile station utilises service specific PLMN preference lists and where the mobile 
25 station then selects the PLMN according to the corresponding preference list for the 
service requested by the user. 

Still another example is given in the Finnish patent FI 105309B where the mobile 
station is aware of the different services supported by different available PLMNs and 
30 where the mobile stations selects the PLMN according to the requested service. 

Still another example is given in the US patent application 2003/0114158A1 where 
terminal either directly or indirectly requests intersystem handover in order to 
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establish the requested service. In this patent the preference list in either terminal or 
network is needed in order to tie the specific service to the specific system. 

The disadvantage of these solutions is that the mobile station awareness of the 
5 services available from different PLMNs cannot be easily arranged. Also the support 
of services by different PLMNs may not only depend on the capabilities of the PLMN 
but also e.g. on the load of the networks and then the support of a specific service may 
be time dependent. Also the service availability may be location dependent e.g. as a 
function of the capabilities of the serving cell. Also the disadvantage is the need to 

10 have service/content based preference lists either in terminal or in network. 

Furthermore the optimum PLMN cannot be selected for mobile terminated services in 
which case the mobile station would not be aware of the service in advance and then 
cannot select the appropriate PLMN in advance and the service request would be 
rejected already by the PLMN where the mobile station is attached at the time of the 

1 5 service establishment attempt. Hence the prior art does not provide a solution for a 
fully flexible service request in respect to the terminal and the network capabilities in 
different modes. 

Brief Description of the Figures 

20 

Figure 1 shows a multimode system consisting of a multimode terminal, a number of 
multimode radio access networks and at least one core network. 

Figure 2 shows a flow diagram where the multimode terminal is attached to access 
25 network A and the service X is requested. 

Disclosure of Invention 

The generic problem solved is the generic case where a multimode terminal is served 
30 by one system and the terminal supports a service that is not supported by the serving 
system, but likely would be supported by another system (supported by the multimode 
terminal with the other system's coverage available). For example, currently a 
GERAN/UTRAN dual mode terminal cannot request a specific service that it supports 
only in the UTRAN mode, when it is served by a GERAN network. 
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The invention is that a generic service request signalling is defined where a 
multimode terminal is allowed to request any service that it supports in any of the 
modes (e.g., access technology like GERAN / UTRAN / CDMA2000 / BlueTooth / 
5 WLAN / . . .) supported by the terminal. The network may then decide to move the 
terminal to other system if possible and necessary in order to establish the service. 
The terminal capability indication for each system mode mostly exists already. 

It should be mentioned that it would be advantageous for the network to indicate 
10 support for the generic service request signalling so that terminal would not send 
these requests in case the serving network would not support it. 

The advantages of the invention are that terminal could start the service regardless the 
serving system capabilities and the full control is left to the network. 

15 

The terminal would not need to scan the available modes and reselect the system that 
supports requested service. 

Best Mode for Carrying Out the Invention 

20 

1 . Making service request independent from the serving system mode 
Since a multimode terminal may support a wide range of services where some 
specific services are not supported by the mobile in all system modes and some 
specific services may not be requested from the serving system, it is possible that the 
25 terminal (user) does not reach the service it would be able to support, and a service 
that would be available at the current terminal location through other system modes. 

This problem can be solved by a generic service request procedure that allows the 
terminal to request any of the services it supports, in any of the system modes it 
30 supports, through the current serving system. 

This generic service request can be implemented in several different ways. Normally 
the network should indicate support for generic service requests in order to avoid 
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compatibility problems for new terminals in legacy networks. In case a generic 
service request is allowed, the terminal may: 

- Use existing signalling messages defined for the serving system, but with 
service request parameters that exceed the terminal capabilities in the serving 

5 system mode. An example being 64 kbit/s circuit switched data that is 

supported by GERAN but may not be supported by the terminal in GERAN 
mode. Then the multimode terminal may be allowed to request 64 kbit/s data 
when served by a GERAN network (fig 1 & fig2, for example A=GERAN, 
B=UTRAN), even if it does not support this service through GERAN. The 

10 network may then decide to hand over the dual mode terminal to be served by 

the UTRAN system (when UTRAN coverage and capacity is available 
locally), and the requested service may then be established through UTRAN. 
Alternatively the network may deny this service and the network may then 
negotiate a service on the currently service system that would be supported 

1 5 both by the terminal and network and would be considered acceptable by the 

terminal. 

- A specific signalling container may be built allowing the serving network to 
direct the terminal service request to one or more other systems. Optionally an 
identifier is added to each service request so that the serving system is able to 

20 direct each particular service request container only to the corresponding 

system. Alternatively, ail parallel service request containers are sent to each 
other systems and the other systems identify which container carries a service 
request for itself. In this case it is sufficient that the terminal builds the service 
request in a way that is understood by each of the other systems for which the 

25 request shall be intended. The serving system then does not need to understand 

in detail any of the terminal capabilities on other systems, it is sufficient that 
the service request is transferred to the other system and interpreted locally. If 
the other system is able to serve terminal with the requested service, the 
terminal would be moved to be served by this system and the requested 

30 service would be established there. One potential solution would be that the 

target system responds with a handover command or a network controlled cell 
reselection order that makes the terminal to move to the desired system. 
- The serving system capability may be extended so that it is able to decode also 
service requests for services that are not supported by it (not supported at all 
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by the system mode of the serving system or just not implemented by the 
serving system). This allows a first decision locally by the serving system on 
the terminal service request. The serving system may initiate a handover 
request (or similar) towards another system or it may directly decide to offer 
5 an alternative service that is supported both by the terminal and the current 

serving system and which it expects to be adequate for the concerned terminal. 

2. Network control for system mode reselection when required to serve any 
specific service 

Several proposals have been made to allow the terminal to select the serving system 
according to the service the terminal (user) is requesting at each moment. A terminal 
based system mode selection has several serious disadvantages. Examples of the 
disadvantages are that: 

- The terminal is not in advance aware which service is best supported by each 
alternative system. 

- The terminal is not aware of the load of the alternative system, and then it may 
be that the alternative system is not at all able to serve the terminal, even with 
a lower quality of service, while the original system could have been able to 
serve the terminal with a compromise on quality of service- 
System mode changes generate normally significant signalling load that 
should be avoided when possible. 

System mode changes normally result to short gaps where the MS is 
unreachable from any of the locally available systems. 

25 Clearly it is strongly preferable that the terminal operates on the system where a 

multimode network has put the terminal with different network and cell reselection 
parameters. The terminal should continue signalling through the serving system as 
normally and the control for system selection should be left for the multimode 
network. The solution to maintain full control at the multimode network while still 

30 making it possible for the terminal to be served with a service it wants and which it 
only supports on a non-serving system mode, or that is only supported by a non- 
serving system, can be reached by a generic service request procedure that allows the 
terminal to request a service that it supports under any of the supported system modes, 
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and the generic service request can be sent to the serving network, at lest if indicated 
being allowed by the serving network. 

Detailed Description of the Figures 

5 

Figure 1 is an example of a possible muitimode system; this invention is not limited to 
this example case only. The muitimode terminal supports all the access networks but 
is attached to one of the access networks based on cell selection criteria. Different 
access networks may have different set of services supported as well as the muitimode 
10 terminal may support different set of services which may not be aligned with 

supported services in the access networks. For example possible access networks 
could be GSM/EDGE, WCDMA, CDMA2000, WLAN, BT, etc. 

The flow diagram of figure 2 shows that the requested service is established in the 
15 current access network or in alternative access network based on the muitimode 
terminal and the access network capabilities in different modes. Similar flow 
diagrams are valid if the muitimode terminal is attached to other access networks. The 
muitimode terminal is first switched on (1). The muitimode terminal then selects (2) 
and attaches (3) to one of multiple available access networks, in this example the 
20 muitimode terminal selects access network A. Service X is then requested on access 
network A (4), where the service X is supported by the muitimode terminal in at least 
one of the multiple modes supported by the muitimode terminal and where the service 
is requested independently of the support for that service by access network A or the 
muitimode terminal in the mode supported by access network A. The serving network 
25 then decides (5) either to establish the service in the current mode (6) or decides to 
move the muitimode terminal to another access network. If the service can be 
established at access network B (7), the serving network requests a handover to access 
network B (8), the terminal is handed over to access network B (9) and the service is 
established (10). 
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